There are no steppers and the machine has no positioning problems. Servos are Mitsubishi industrial AC servo, specifically J3 series and they are new.

As I mentioned, if the G93 is removed, the same program with no other changes, cuts correctly. I have been threading on these machines for a couple of years and when Kflop was added the threading continued to work fine. ONLY when G93 was used did things go bad.

 You say that Kflop receives coord vs time and this is where the problem is. The speeds seem correct, but the motion coordination goes bad, specifically the X axis position .

Threads are cut in six passes. At the end of the run the X axis has lost registration. The servo is no longer in the right position, but something that I did not check is to see if the DRO is showing the correct X position.

I will get that info and post back. Note that I have no way to test MACH without the Kflop at this time, so I cannot discover for myself if G93 works correctly using the PP.

More info: MACH is definitely not running the G-code properly, so the problem *might* be the symptom of another MACH bug.

As I am aware of some past anomalies in MACH's handing of subroutines, I put some debug stuff in the program to report certain statuses on the Mach message line and it turns out MACH was skipping directly to iteration 5 (of 15).    (note I stated 6 'passes' previously, but the thread area is actually divided into 6 sections and each section requires multiple passes to complete, the number being determined by the width and depth of the particular section)

As in previous MACH weirdness, a solution was to insert delays. Mach does not track threads very well and using variables and math in a G-code program can cause MACH to get ahead of itself. 

NOTE: Just as an FYI, this behavior is particularly nasty when using macros. MACH apparently hands off the macro to VB and then continues immediately to run the next G-code block. If the program uses a variable that will be updated by the script, MACH may pass that block of G-code before the var is updated, thereby using the wrong data. This required the work around of adding flags and delays to assure MACH waited for the new data.

A related FYI: MACH now can run named scripts and that facility automatically causes MACH to wait for the named script to return, thereby eliminating the need for all of the smoke and mirrors.

In the case of my threading program, apparently with G93 mode on, MACH was counting phantom macro iterations in the background somehow and starting on iteration 5 instead of 1. Each iteration used a pair of updated vars and there was some simple math in the  subroutine. Exactly the conditions that can make MACH misbehave. Inserting a delay at the end of the sub cleared the problem.

I have not tried this fix on the actual machine yet, but I will report back if the problem persists. Meanwhile, I hope this proves helpful to anyone having similar issues.